REMARKS 

Claims 1-8 are pending. Claims 1-8 are rejected. Claims 1, 3, 5, 7, and 8 are 
amended. 

Applicants submit the following remarks and respectfully request reconsideration 
of the application. 

Specification 

The Office Action states that the Specification of 10/15/01 has not been entered 
because of lack of a clean version of the Specification. 

The response to notice of missing parts dated 10/15/01 included a preliminary 
amendment that did contain a clean version of the Specification in Appendix C. 

To address the Examiner's objection and to resolve the issue, Applicants resubmit 
a clean and marked-up copy of the Specification. 

In the Specification, please replace the Specification with the Substitute 
Specification in Appendix A. The marked-up version of the Specification is in Appendix 
B. The Substitute Specification does not contain any new matter. 

Rejection Under 35 U.S.C. §102(e) 

Claims 1-8 stand rejected under 35 U.S.C. §102(e) as being unpatentable over 
U.S. Patent 6,629,152 (Kingsbury) . 

Claim 1 recites a means for comparing a resulting value of the first uninterruptible 
operation stored in the affected reservation location to limit values stored in limit 
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locations and means for performing a second uninterruptible operation to restore the 
affected reservation location if the resulting value of the first uninterruptible operation is 
not within the limit values in the limit locations. 

Kingsbury teaches message passing between processes using a mailbox data 
structure (Abstract). FIG. 6 of Kingsbury discloses sending a message using a mailbox 
data structure. However, Applicants fail to see how Kingsbury anticipates means for 
comparing a resulting value of the first uninterruptible operation stored in the affected 
reservation location to limit values stored in limit locations. The cited portion of 
Kingsbury in step 92, col. 10, lines 26-33 discloses checking if a sampled value indicates 
that the mailbox data structure is full. This cited portion of Kingsbury does not teach or 
suggest comparing a resulting value to limit values stored in the limit locations as recited 
in claim 1. The checking in step 92 in Kingsbury is merely to check whether a mailbox 
data structure is full as opposed to comparing the resulting value with the limit values to 
check whether the resulting value is within the limit values. Additionally, Applicants fail 
to see where Kingsbury teaches or suggests the limit values that are stored in limit 
locations. These limit values in the limit locations can dynamically change to provide 
flexibility in checking the resulting value. Kingsbury , on the other hand, only has one 
static value for the limit to indicate the end of the mailbox data structure. 

Claim 1 also recites means for performing a third uninterruptible operation to 
update an actual value location if the resulting value of the first uninterruptible operation 
is within the limit values in the limit locations. The Office Action cites Step 104, col. 10, 
lines 58-61 in Kingsbury to teach this limitation. However, a closer reading of col. 10, 
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lines 58-61 reveals that the changing of n_present to indicate that a message is present in 
a message slot does not teach an uninterruptible operation as recited in claim 1. 

Claim 1 also recites meansfor reporting a failure if the resulting value of the first 
interruptible operation is not within the limit values in the limit locations. In col. 9, lines 
1-15 of Kingsbury , the MBOX_FULL„NO_SLOTS_ERROR is in response to the 
mailbox being full as opposed to being in response to a resulting value not being within 
limit values as recited in claim 1. Similarly, the SUCCESS message is in response to the 
mailbox being not full as opposed to being in response to the resulting value being within 
the limit values as recited in claim 1. Therefore, claim 1 is allowable over Kingsbury for 
at least the above reasons. 

Claim 2 is dependent on claim 1 and is allowable for at least the same reasons as 
claim 1. Claims 3-8 are also allowable for at least the same reasons as claim 1. 
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Conclusion 

In view of the above remarks this application is in condition for allowance, and 
the Examiner is respectfully requested to allow this application. The Examiner is invited 
to call Applicants' representative at the number below if he has any questions or if there 
are remaining outstanding issues. 



Respectfully submitted, 
Herbert W. Sullivan et al. 



Date: ^/iS/p l| By: ^La ^^^^^^ 

^Eugene Kim, 



ugene Kim, Reg. No. 46,267 
Carr & Ferrell LLP 
2200 Geng Road 
Palo Alto, CA 94303 
Phone: (650)812-3400 
Fax: (650) 812-3444 
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Appendix B 
Marked-Up Version of the Specification 



METHOD AND SYSTEM FOR ENHANCED CONCURRENCY IN A COMPUTING 

ENVIRONMENT 

BACKGROUND OF THE INVENTION 

CROSS REFERENCE TO RELATED APPLICATIONS 

The present application claims priority from U.S. 
Provisional Patent Application Ser. No. 60/168,861, filed 
on December 2, 1999 by Herbert W. Sullivan and Clifford L. 
Hers h, the complete specification of which is hereby 
incorporated by reference . 

DE S CRIPTION OF THE BACKGROUND OF INVENTION ART 

The present invention rclatcQ generally to 
multitasking computer systems, — and more particularly, — fee 
multiprocessor systems and a mothod for increased 
concurrency in such systems. 

Multiprocessor computing systems have been used for 

years to perform multiple tasks. A multiprocessing 

computing system may bo defined as a computer assembled 
from a plurality of independently or semi independently 
operating intelligent, — i.e., processor based, — stations *. 
The stations arc generally interconnected for communication 
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by a communication bug . Each processor may perform a 

plurality of tasks with apparent concurrency. Distributing 

the system intelligence among a plurality of stations may 
improve the processing throughput of the computing system, 
allow the system to modularly and uniformly expand to meet 
increasing computing requirements, — and permit greater 
efficiency and productivity through concurrency. 

While multiprocessor computing systems arc known, — they 

arc not scalable. The software of such systems is often 

highly dependent upon the configuration and characteristics 

of the system hardware. This moans that the scalability of 

the multiprocessor is limited. Further, — the dependency of 

the software on the hardware often causes a waste in 
processor resources . 

Synchronizing or coordinating the tasks using a 
central processor to enhance concurrency of a plurality of 
tasks has been problematic in most multiprocessor systems. 
The prior patents of Sullivan, U.S. — Patent Nos. — 4 , 4 8 4 , 262, 
4,707,781 and 5,438,680, the disclosures of which are 
incorporated heroin by reference, — addressed some issues 
relating to enhancing concurrency. 

The Sullivan patents describe that concurrency can be 
enhanced by communicating between processors or tasks via 
commonly accessible memory to reduce conflicts within the 
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multiprocessor system. However , — the diocloocd techniques 

arc primarily dependent on hardware, — such as the 
processors . 

Uninterruptible or atomic operations are operations 
that cannot be interrupted by another processor or by 
another thread on the same processor. Intel processors, 
for example, perform addition as an atomic machine 
instruction with extremely short locking implemented by a 
cache coherency mechanism. A LOCK prefix implements the 
atomic operation for a set of operations that do read- 
modify-write operations on a single memory address such as 
the LOCK XADD instruction (Exchange Add) . The lock time of 
atomic instructions is generally very short. 

Current technology suffers from the inability to add 
or subtract from a shared memory location without locking 
the location during the operation if it is necessary to 
keep the value within limits or maintain a valid 
transaction log. Using atomic operations, it is possible 
to add or subtract without locking which causes blocking, 
provided that there are no limits and a valid transaction 
log is not necessary. 

Therefore, a need exists for a system and method for 
enhancing concurrent computation with shared resources. 
Further, a need exists for a software-based system that is 
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capable of enhancing the concurrency of any multiprocessor 
computing system. 
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SUMMARY OF THE INVENTION 

In one aspect, — the invention is directed to a method 
5 for operating a computer system., — The computer includes at 
least one processor. — The method includes establishing a 
plurality of memory units each having a corresponding 

memory location. A plurality of tasks running on the 

processor arc executed, — and the plurality of tasks arc 

10 operable to share data. A plurality of lists for each 

memory location arc defined, — and at least one of said lists 

is locked if the data is invalid. An entry is inserted 

into said locked list corresponding to one of said tasks. 
The locked list is unlocked, — and a determination is made if 

15 data is inputted in the memory location between the 
determining step and the unlocking step. 

In another aspect, — the invention is directed to a 

method for operating a computer system. The system 

includes at least one processor. The method includes 

20 establishing a plurality of memory units each having a 

corresponding memory location. A plurality of tasks arc 

run on said processor, — and the plurality of tasks arc 

operable to share data. An entry corresponding to one of 

the tasks is inserted into one of the lists if the list is 
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unlocked. The method also includca determining if another 

of said lists is unlocked if said one liot is locked. 

In another aspect, — the invention is directed to a 
method for synchronizing processes in a computer ays tern. 

5 The computer system includca at least one proccooor. The 

method includes establishing a plurality of memory units 

each having a corresponding memory location. A plurality 

of tasks running on the processor are executed, — and the 
plurality of tasks arc operable to share data located in 

10 the memory units. A plurality of lists for each memory 

location arc defined. A list is locked if the data is not 

valid. An entry is inserted into the locked liot 

corresponding to one of the tasks, — and the list is 
unlocked. The entered task is suspended until valid data 

15 is found in the memory unit. The method also includes the 

steps of reading valid data and determining if other data 
appears in said memory location before said locking step 

and after said unlocking step. The other data is read if 

it appears in the memory unit. 

20 Implementations of the invention include one or more 

of the following. The locking step further comprises 

activating selected other ones of oaid plurality of tasks 

that are entered on said locked lists. The plurality of 

lists may form a linked liot. The plurality of lists may 
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be between four and eight. The method may aloo include the 

step of transferring the operation of oaid locked list when 
said locked liot io locked by another one of said plurality 
of tasks. 

5 In another aspect, — the invention io directed to a 

computer system having enhanced concurrency that includes a 

plurality of processors. A plurality of tasks arc run on 

the plurality of processors. The computer system may also 

include a plurality of memory units each having a 
10 corresponding memory location; — and a plurality of lists 

corresponding to each of said memory locations. One of 

said tasks may bo responsible for activating selected ones 
of said plurality of tasks contained on the same list as 
said one task. 

15 In yet another aspect, — the The invention provides a 

system and method for adding and subtracting within limits 
without blocking. A thread comprises an operation 
including either addition of an addend or subtraction, 
which is performed as addition of a negative of the addend. 

20 The operation affects a shared actual value stored in an 
actual value register. Upper and lower limit registers 
store permissible upper and lower limits within which the 
result of the operation must fall. Addition and 
subtraction reservation registers, which are also shared 
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resources, store a reserved value after an addition to the 
actual value or after a subtraction from the actual value 
respectively. 

The method includes getting the value of the addend. 
5 If the operation is addition the value of the addend is 

positive, otherwise it is negative. A LOCK XADD operation 
using the addend is performed on an affected reservation 
register, i.e., the addition reservation register if the 
operation is addition or the subtraction reservation 

10 register if the operation is subtraction. The resulting 

value in the affected reservation register is then compared 
to the value of the limit registers. If the operation 
cannot succeed, the addend is added back to the affected 
reservation register in a LOCK XADD operation and a failure 

15 is reported. 

If the operation can succeed, in a LOCK XADD operation 
the addend is added to the value of the actual value 
register. Finally, in a LOCK XADD operation, the addend is 
added to the value of the unaffected reservation register 

20 which was not affected by the first atomic operation and a 
success is reported 

Aspects of the invention include a computer- 
implemented method for adding and subtracting within limits 
without blocking. Another aspect of the invention provides 



{00112257vl} 



a system having a central processing unit (CPU) and a 
memory which are configured to effect the method described 
above. Another aspect includes a computer program recorded 
on a computer readable medium for causing a computer to 
5 effect the method as described above. 

The foregoing and other objects and advantages of the 
disclosed system and method will become apparent to those 
of ordinary skill in the art after having read the 
following detailed description of the preferred embodiments 
10 that are illustrated in the various drawing figures. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FICs . — ID arc flowcharts illustrating a preferred 

method of reading data from a mailbox. 

FICs. 2A 2D are flowcharts illustrating a preferred 

5 method of inputting data in a mailbox. 

FIG. 3 is a flowchart of a "one last look" method. 

FIGo . — 4 2 4 illustrate additional aspects of the 

invention . 

FIG. OS- 1 illustrates a portion of a conventional 
10 computer system, including a CPU and a memory, in which the 
present invention may be embodied. 

FIG. 2-& illustrates a system block diagram in 
accordance with a preferred embodiment of the invention. 
FIG. 03- 3_ illustrates the overall process for 
15 implementing a method for adding and subtracting within 
limits without locking. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT S 

The present invention is directed to a system and 
method for enhancing concurrency in a multiprocessor or 

multitasking computer system. A multitasking computer 

system may bo defined as a computer system that permits 
multiple threads of execution in a single execution space. 
A multiprocessing computer system may be defined as a 
computer system that allows multiple processing units to 

share data. Preferably, various tasks in the computer 

system communicate using commonly accessible "mailboxes . " 
A mailbox is an area of memory that contains a number of 

states, and may be identified by a virtual address. When 

one task produces an item of valid data that may be desired 
by multiple other tasks, — the task holding the valid data 

inputs it into a mailbox. Generally, — other tasks read the 

valid data from the mailbox. 

In accordance with a preferred method, — the task that 
inputs the valid data into the mailbox is caused to notify 
other tasks addressing the mailbox that the data is 

contained therein. This means that there is no need for 

central coordination of mailbox acccosos. Further, — this 

minimizes busy waits for valid data. This permits tasks 

and processors to allocate their resources more 
productively . 
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Ao stated above, — the mailbox io a memory location. 
The mailbox includes a pointer to the address corresponding 

to valid data. Alternatively, — a number, — ouch ao a string 

of zeros , — io employed if the data io invalid. F&e 

simplicity, — the preferred method will be described with 
reference to inputting or reading data to or from the 

mailbox. However, — the data to bo accessed can be located 

in the same memory system as the mailbox. Further, — fefee 

term "task" refers to a set of instructions running on a 

process . Thus, — the processor executes the task. 

Additionally, — the terms "invalid" and "valid" refer to 

arbitrary logical status. In the preferred method, — a task 

roads valid data and docs not read invalid data. Other 

states may be used such as "true" and "false". 

A plurality of lists of tasks wait for valid data 

associated with the mailbox. By coordinating several lists 

in accordance with the preferred method, — conflicts in 
accessing data and delays in obtaining data can bo 

minimized. This is because only a small number of 

instructions, — for example, — under 30, — are required to read 

or place data to or from the mailbox. Those functions 

occupy a small percentage of a task's activity time, — such 

as 5% or loos. Accordingly, — it has been found that a 

smaller number of lists can eliminate moot conflicts. 



{00I12257vl} 



12 



However , — a liot for each active task may be required to 
eliminate all conflicto. — Any number of lioto may be uocd. 
For example, — the number of lioto may be between four and 
eight . 

In the preferred method, — the lioto arc a linked liot. 
A linked liot can employ locationo in the oamc memory 

system ao the mailbojceo. The linked liot includco 

locationo having ouitablc apace for at least two pointcro . 
The locationo in the middle of the liot may contain a 
forward pointer to the next location including the liot, 
and a backward pointer to the preceding location including 

the liot. Additionally, — the top location on the liot may 

contain a pointer forward to the next location and a 

pointer backward to an illegal addrooo, — ouch ao zero. Qrhe 

bottom location on the liot can contain a pointer backward 
to the preceding location and a forward pointer to an 

illegal addrcoo, — ouch ao zero. When an item, — i.e., — data, 

io added to the liot, — the forward pointer corrcoponding to 
the proviouo bottom location io changed to corroopond to 

the location of the added item. Aloo, — the added item 

bocomco the now bottom location. When the top item io 

taken from the liot, — the next item in the liot rcplacco the 

top item. Additionally, — the backward pointer of the added 

item io changed to point to an illegal addrcoo, — ouch ao 
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zero . When both pointers of an item in a mailbox arc to an 

invalid address, — tho list io oonoidorod empty. 

Reading Valid Data When Availabl e 

FIGs 1A ID arc flow charts showing a preferred 

method for reading data from a mailbox. Initially, — data in 

a mailbox is read (stop 101) . In the preferred method, — the 

mailbox may contain a pointer to the memory location 
containing tho desired valid data or an illegal address 

corresponding to invalid data, — such as zero. The mailbox 

is then addressed and interrogated to determine if the data 

is valid — (stop 102) . At this stage, — a mailbox may contain 

or is, about to contain data associated with a program of a 

task seeking such data. If valid data is in the mailbox, 

it is read from tho memory address indicated in the mailbox 
(step 10 4 ) . The task may also read tho data during step 

One aspect described herein is that tho task 
performing stops 101 and 102 contacts other tasks waiting 

for valid data from that mailbox. This means that 

conflicts are avoided in tho multiprocessor system because 
busy waits for valid data are minimized. 

t FIGo 1A ID illustrate lists L0 and Ll that represent 

tasks waiting to receive valid data from a mailbox, — 
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FIGg . 2A 2D ohowo lioto L2 an dL3 that identify taoko 

waiting to input valid data in the mailbox. 

Ag shown in FIG. — 3rA^ — a task liot io locked when it io 

manipulated by a taok. Thio prcvcnto acccao by other taoko 

to that liot. After liot LO io locked (otop 106), — the taok 

dctcrminco if liot L0 wao previoualy locked by another taok 

(otcp 108) . If liot LO wao previouoly locked by another 

taok prior to the current taok executing otcpo 106 or 10 8 , 

tho prior taok operatco liot LO . The current taok then 

proceeds to check liot Ll — (otcp 122 ) , — ao doocribcd below. 

If liot LO wao previouoly locked — (otcp 108) , — fefee 

current took dctcrminco if liot L0 io empty — (otcp 110) . £# 

the liot L0 io not empty, — the current taok then rcmovco the 

firot waiting taok — ( "waiter" ) — from tho liot — (otop 116) . A 

waiter may bo defined ao a taok that waito for valid data 

to bo in a mailbox. In thio configuration, — a waiter may bo 

in a ouopended otato, — ao doocribcd below. Tho current taok 

then unlocko liot L0 ouch that other taoko may aeccoo the 

liot — (otcp 118) . Addi t i ona 1 ly , — the current taok oauooo the 

taok associated with that waiter to execute a wake code 

(otcp 120) . A wake code may be defined ao a oet of 

computer inotructiono that cauoe a taok to activate from a 

ouopended mode. Then, — the current taok again loeko liot L0 

(otcp 106) . Thio proocoo continuoo until each taok on liot 
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LO hao been notified, — and the liot LO io empty. 
Alternatively, — thio proccoo may continue until the liot LO 

hao been found locked. If thia liot ia empty, — liot LO io 

unlocked (otcp 112), and the took procoodo to check liot Ll 
(otcp 122) , — aa deocribed below. 

If liot LO wao proviouoly locked (otcp 108) , — febe 
current task locko liot Ll (otep 122), and then checko if 

that liot wao proviouoly locked — (otcp 124) . If liot Ll wao 

not proviouoly locked at otep 12 4 , — the current taak 

dotormincb if liot Ll io empty (otcp 128) . If liot Ll io 

not empty, — the current taok romovoo the waitcra from liot 
ti — (otcp 132) — and cauoeo the waitcra to execute their wake 

codoo — (otep 13 4 ) , — ao deocribed above. Thio proccoo ropcato 

until liot Ll ia empty or the liot Ll hao been found 
locked. — When liot Ll ia empty, it io unlocked (atop 130) . 
The taok then continueo to execute ita remaining 

inatructiona ao defined by the oyotcm (otep 126) . If liot 

Ll wao proviouoly locked by another taok prior to otcpo 

122 , — 12 4 or 126, — that taok oporatco the locked liot. ¥he 

current task then oxecutco otep 12 6. 

Valid Data Not Available 

If no valid data ia found at the mailbox — (atop 102) , 
liot LO io locked (otep 1 4 0) . The current taak then 
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determines if liot LO wao previously locked (otcp 1 4 2) . — i# 
the liot wqo not previously locked, — the current task is 

entered on list LO — (stop 1 4 4) . List LO is then unlocked 

(step 1 4 6), and the current task checks for valid data 

(step 148) . The current tasks then determines the validity 

of the data — (stop 150) . This above process may be referred 

to as "one last look," as described below. In the 

preferred method, — this configuration keeps two or more 
tasks , — which arc synchronised by passing data through the 
mailbox, — from missing each other. 

If the data is still not valid at step 150, the task 

is suspended (step 152) . This releases computer system 

resources for other tasks, — or the task can complete other 

system instructions. This means that the task does not 

busy wait or periodically 'check for valid data in the 

memory location. The current task will bo activated by 

another task which has found valid data in the memory 
location, — or by a task which previously inputted the valid 

data — (step 15 4 ) . When activated by another task, — fcke 

current task proceeds to road the valid data from the 

mailbox (step 10 4 ) . If the data is valid (otcp 15 0) and 

list LO was previously locked (steps 156 and 15 8 ) , — fefee 
current task is suspended until activated — (steps 152 and 
15 4 ) . When activated by another task, — the current task 
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proccodo to read the valid data from the mailbox — ( otcp 
10 4 ) . 

If the data was valid — (otcp 150) — and the current taok 
determines that liat L0 wao not looked — (atop 156 and 159), 

the current task rcado the data. Thio may occur ao the 

current taok dctcrminco the validity of the data. — , Then, 
the current taok cxccutco otop 202. 

If the current taok io on the liot L0 at atop 202, — fefee 

current taok io removed from the liat — (otop 20 4 ) . The next 

waiting taok io aloo removed from the liot L0 — (otop 206) , 

and liot L0 io again unlocked — (otcp 20 8 ) . The taok then 

causes the other taok removed from the liot to execute ita 
wake code — (otcp 210) . 

Next , — in accordance with the preferred method, — fcke 
current taok dctcrminca if the liot L0 wao prcviouoly 

looked — (otopa 212 and 21 4 ) . If ao, — the current taok then 

oxecuteo other oyotcm inotructiono — (otcp 220) . If the liot 

wao not prcviouoly locked, — the current taok then dctcrminco 
if the liot io empty — (otop 216) ■ 

If liot L0 io not empty — (otcp 216) , — the current taok 
loopo back to remove and notify the next taok at the top of 

the liot — (otcpo 206 — : — 216) . If on any ouch loop, — the liot 

io found looked at otcpa 21 4 or 216, — the current taok 
continuco to perform other oyotom inotructiono — (otcp 220) . 
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When the liat io empty, — it io unlocked (atop 218) — and the 
current task oontinuco to perform other oyotcm inotructiono 
(otcp 220) . 

The current taok may not be on the liot L0 — (otcp 202) . 
Thio moano that another taok hao removed the current taok 

from the liot and io operating to activate it. However , 

the current task aloo opcratco liot L0 . Thuo, — the current 

taok muot activate the other tasks on liot L0 . The current 
task may then suspend itoclf until activated by another 
taok, 

Ctcpo 228 through 238 operate oimilar to otepo 206 

through 21 8 . However, when liot L0 io found locked (otcp 

23 4 ) — or empty — (otcp 236) , — the current taok io suspended 

(otcp 2 4 0) . When activated by another taok — (otcp 242 ) , — fcfee 

current taok prococdo to read the valid data from the 
mailbox — (otcp 10 4 ) . 

Referring again to FIG. IB, — if liot L0 wao locked 

(otcp 1 4 2 ) , — the current taok proccodo ao follows. Liot Ll 

io locked and then the current taok dotcrmineo whether that 

liot wao prcviouoly locked (otepo 180 and 1 8 2) . If liot Ll 

wao proviouoly locked, — the current taok rcturno to lock 
liot L0 — (otcp 1 4 0) , — and continuco to ocarch for an unlocked 
liot . Thio example providco two poooiblc lioto. However , 
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more lists may be used. If , the number of lists equals the 

number of tasks, — no task will repeat this loop. 

If list LI was not previously locked — ( stop 182 ) , — fefee 
current task becomes a waiter on list Ll — (step 18 4 ) , — fefee 
list Ll is unlocked — (stop 1 8 6) , — and a "one last look" check 

is made for valid data (steps 1 8 8 and 190) . If the data is 

not valid, — the current task is suspended — (step 152) . 

If the data is valid (step 190) , — then the current task 
reads the data as it confirms the validity of the data. 
List Ll is then locked — (step 192 ) , — and a chock is made 

whether it was previously locked — (stop 19 4 ) . If list Ll 

was previously locked — (step 19 4 ) , — list Ll is unlocked — (step 
196) , — and the current task is suspended — (step 152 ) . 

If the data was valid and it is determined that list 
Ll was not locked, at steps 190, — 19 4 , and 196, 
respectively, — then the current task proceeds — (step 252) . 

FIG . — ID shows that if the current task is on list Ll 
(step 252) — that task is removed from the list — (stop 25 4 ) , 
and also removes the next waiting task from the list Ll 

(stop 2 56) . The task then unlocks list Ll again — (stop 

258) . The task then causes the other task removed from the 

list to execute its wake codo — (step 260) . 

Next , — the current task determines whether the list Ll 
was previously locked — (steps 262 and 26 4 ) . If it was not 
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previously locked, — the current task determines whether the 
list is empty — (atop 266) . 

If list LI is not empty — (atop 266) , — the current tack 
loops back to activates tack at the top of the list — (stops 

256 through 2 66) . If on any such loop, — the list is found 

locked at stops 26 4 or 266, — the current task continues step 
(270) . — When the list is empty, — it is unlocked — (stop 261) , 
and the current task continues to execute other system 
instructions — (step 270) . 

If the current task is not found on the list LI' — (stop 
252 ) , — this moans that some other task has taken the current 

task off the list and is attempting to activate it. The 

current task also operates list Ll . Thus , — this task must 

activate the other tasks on list Ll before suspending 

itself . The current task can then bo activated by another 

task. The method of steps 27 8 through 288 is similar to 

steps 256 through 268 described above. However , — when list 

Ll is found locked — (step 2 84 ) — or ompty — (step 286) , — the 

current task is suspended — (step 290) . When activated by 

another task — (step 292 ) , — the current task proceeds to road 
the valid data from the mailbox at stop 10 4 . 

This preferred method of finding an available list is 
simple. Further, — a task should not be significantly 
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delayed in finding an unlocked liot. Thus, enhanced 
concurrency can be achieved over prior oy stems . 
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Inputting Valid Data 

FIGg . — 3A 2D arc flow charts showing the input of 

data into a mailbox in accordance with the preferred 

method. Initially, — data io road in a mailbox (atop 301) . 

The mailbox is then addressed and interrogated to determine 

whether the data io valid (otcp 302) . If valid data io not 

already in that mailbox, — the mailbox io marked as not 
containing valid data. — Next , — the valid data io placed in 
the mailbox (otcp 3 0 4 ) . 

In accordance with the preferred method, — lists L2 and 
L3 identify tasks waiting to input valid data in the 

mailbox. This includes a current taok waiting to input 

data in the mailbox. The current taok determines whether 

list L2 wao previously locked (otcp 3 0 4 ) . If so, — that list 

remains locked (step 306) . If list L2 was not previously 

locked the current task determines whether list L2 is empty 

(otcp 310) . If the list L2 is not empty, then the current 

task rcmovco the first waiter from that list — (step 316) . 
Also, — the current taok unlocks list L2 so that other tasks 
may access it — (step 318) , — and causes the task associated 
with that waiter to execute its wake code (step 320) . 

Then, — the current task locks list L2 again (step 306) . Tfee 

above process continuco from step 306 until all taoko on 
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list L2 occking the valid data from the mailbox have boon 
activated . — Al t orna t i vo ly , — thio procooa continuoo until the 
liot L2 io empty, — or the liat L2 haa been found locked. 
When list L2 ia found empty, — it ia' unlocked — (otcp 312 ) , — aed 
the current taok procccdo to liat L3 — (otcp 322) . 

If liat L2 wag prcviouoly locked — (atop 301) — or liot L2 
waa found empty — (otcp 310) — and then unlocked — (otcp 312) , 

the current taok then locko liot L3 — (otcp 322) . Then, — the 

current taok checko if liot L3 waa prcviouoly locked (otcp 
32 4 ) . — If liot L3 wao not prcviouoly locked, — the current 

taok dotorminca whether liot L3 io empty — (otcp 32 8 ) . 

liot L3 io not empty, — the current taok proccoda to remove 
the waiters from liot L3 — (otopo 332 and 33 4 ) — and cauoco 

them to execute their wake codes — (atop 306) . Thio proccoo 

repcato by looping back to otcp 322 . The procooa may 

continue until liot L3 ia empty or haa been found locked. 
When liot L3 io empty, — it io unlocked and the current taok 
continuoo to execute other oyotcm inotructiono — (otcpa 330 

and 338) . If liot L3 io found to have been previouoly 

locked at otcpo 322 or 32 4 , — thio indicatco activity by 

another taok. The current taok then executeo other oyotcm 

activitico — (atop 338) . The current took aloo defcro to the 

other taok to activate the other taoko liotcd on liot L3 . . 
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Valid Data Found in Mailboic 

If the current taok determines that there io valid 
data at the memory location (otep 302), — the list L2 io 

locked ( step 3 0 4 ) . The current task aloo checko whether 

the liot wao prcviouoly locked — (atop 342) . If liot L2 wao 

not previously locked, — the current taok ia inocrtcd onto 
liot L2 — (otep 34 4 ) . — Liot L2 ia then unlocked (atop 3 4 6) 
and a "one laot look" check io made for valid data (otopo 

3 4 8 and 350) , — ao deocribed below. If the data io otill 

invalid, — the current taok io ouapended (atop 352) . The 

current task io then activated by another taok that hao 
found or inputted valid data in the memory location — (otep 
354) . 

If the data in the mailbox ia valid and liot L2 wao 
prcviouoly locked — (atcpo 356 and 358) , — the current, taok ia 

ouapended until activated — (otcpo 352 and 35 4 ) . When 

activated by another taok, — the current taok procccda to 
input valid data into the mailbox — (otep 30 4 ) . 

If the data wao not valid — (otep 350) — and liot L2 wao 
not prcviouoly locked — (otcpo 35 6 and 368) , — the current taok 
continuco to execute other oyotcm commando — ( otep 402 ) . 

If the current taok io on liot L2 — (otep 4 02) — fehe 
current taok rcmovco itoclf from that liot — (otep 404) . 
Aloo, — the current taok rcmovco the next waiting taok from 

/ 
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the liot L2 — (atop 406) — and unlocks liot L2 again (step 

4 08) . The current task then causes the other task to bo 

removed from the list to execute its wake code — (atop 4 10) . 

In accordance with the preferred method, — the current 
task determines whether the liot L2 was previously locked 

(steps 4 12 and 4 1 4 ) . If so, — the current task proceeds to 

input valid data in the mailbox — (step 30 4 ) . Otherwise, — fefee 

current task determines whether the list is empty — (step 
416) . 

If list L2 — is not empty — (stop 4 16) , — the current task 
loops back to remove and activate the next task at the top 

of the list — (stops 4 06 416) . If on any such loop, — fefee 

list is locked at stops 4 1 4 or 4 16, — the current task inputs 

valid data in the mailbox — (step 30 4 ) . When the list is 

empty, — it is unlocked — (step 4 1 8 ) . The current task then 

inputs valid data in the mailbox — (stop 30 4 ) . 

If the task is not on tho list L2 — (step 4 02) , — fche 
current task may be removed from the liot and is being 

activated by another task. The current task also operates 

list L2 . Thus, — the current task must activate the other 

tasks which arc on list L2 before suspending itself. The 

current task may then bo activated by another task. ¥he 

method of steps 4 28 through 4 38 is similar to steps 4 06 
4 18 . However, whon liot L2 is found previously locked 
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( step 4 3 4 ) — or empty — (otcp 4 36) , — the current task io 

suspended — (otcp 4 4 0) . When activated by another task — ( stop 

44 2 ) , — the current task proceeds to input valid data in the 
mailbox (step 30 4 ) . 

If list L2 was previously locked at otcp 3 4 2, — fcfee 
current task locko liot L3 (otcp 3 8 0) — and then determines 

whether that liot wao prcviouoly locked — (otcp 382) . 

liot L3 was previously locked, — the current task loops back 
to attempt to access list L2 — ( otcp 3 4 0 ) , — and continuco to 

find an unlocked list. Thio example provides two possible 

lists . However, — more than two lists may be employed. 

If list L3 was not previously locked — (otcp 382 ) , — fefee 
current task io inserted on liot L3 ao a waiter — (stop 38 4 ) . 
The list L3 is also unlocked — (stop 386) , — and a "one last 
look" check io made for valid data — (atcpo 388 and 390), — as- 

deocribed below. If the data io valid, — the current task is 

suspended — ( step 352 ) . 

If the data is not valid (otcp 390) , — list L3 is 
locked, — (otcp 392) — and a check io made whether liot L3 wao 

prcviouoly locked (otcp 394) . If liot L3 wao prcviouoly 

locked, — liot L3 io unlocked (otcp 396) , — and the current 

taok io ouapended (otcp 352) . If the data wao not valid 

and the liot L3 wao not prcviouoly locked (otcpo 390, — 39 4 , 
and 396) , — the current taok procccdo to otcp 4 52. 
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If the current taok io on liot L3 — (atop 452) , — it io 

removed from that list (atop 4 5 4 ) . Moo, the next waiting 

taok from the liot L3 ia removed (atop 4 56), — and the 

current taok unlocks list L3 again (otcp 4 58) . The current 

taok then cauoco the other taok removed from the liot to 
execute ita wake code — (otcp 4 60) . 

The current taok then dotcrmineo whether the liot L3 

wao previously locked — (otopo 4 62 and 4 6 4 ) . If it wao not 

proviouoly locked, — the current taok dctorminca whether the 
liot is empty — (otcp 4 66) . 

If liot L3 io not empty, — the current task loopo back 
to remove and activate the next taok at the top of the liot 

(otcpo 4 56 4 66) . If on any ouch loop, — the liot io locked 

( steps 46 4 and 466) , — the current taok inputs valid data in 

the mailbox (otcpo 30 4 ) . When the list io empty, — it io 

unlocked — (otcp 4 68) , — and the current taok determines if 
valid data io inputted in the mailbox — (otcp 3 0 4 ) . 

If the current taok doco not find itoclf on liot L3 
(otcp 4 52) , — thio may be becauoc oomc other taok hao taken 

the taok off the liot and io trying to activate it. ¥fee 

current taok, — however, — operates liot L3 . Thus, — the current 

task muot activate other taok on liot L3 before ouopending 

itoclf . The current taok then may be activated by another 

task. The method of stops 4 7 8 through 48 8 io oimilar to 
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steps 4 56 through 468. However, when list L3 is found 

previously locked (stop 4 8 4 ) — or empty (step 4 86) , — fefee 

current task ia suspended — (stop 490) . When activated by 

another task — (atop 4 92 ) , — the current task proceeds to input 
valid data in the mailbox — (atop 30 4 ) . 

Ono Last Look 

The term "one last look" refers to the situation where 
a task that has placed itself on a list for valid data from 

a mailbox receives that data. The preferred method allows 

tasks addressing the same mailbox to be coordinated. This 

means that a current task inputting valid data in a mailbox 
will activate another task that was entered onto a wait 
list, while the data was placed in the mailbox by the 

current task. Accordingly, — a current task may not input 

valid data in the mailbox, while another task is inserted 

on a list to rocoivo that data. The preferred method 

avoids the potentially infinite period of time that a task 

may sleep until another task activates it. Thus, — delays in 

system processing time may be minimi gcd. 

FIG . — 3 — shows that a task first looks at the data in 
the selected mailbox and determines whether it is valid 
data — (steps 5 48 and 550) . If the data is valid, .it" reads 
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the data and continued with other oyotcm activities — (otcpo 
551 and 553) . 

At this otagc, — if the data io not valid, — the taok io 

inserted onto a wait liot — (atop 555) . Then, — the "one loot 

look" dctcrminco if the data io valid (otcpa 557 and 559). 
Thia oocuro bocauoc, — while the taok that may have located 
an unlocked liot, — locked it, — placed itoelf on the liot and 
unlocked the liot again, — another taok may have put valid 

data in the mailbox. Without thio preferred "one loot 

look" method, — activating the inserted taok may be delayed 
until another taok oecko valid data from the mailbox. 

If the data io not valid at that time, — the taok will 
ouopend until activated by another taok, — ouch ao the next 
taok inputting valid data in the mailbox — (otopo 552 and 
55 4 ) . Thio method corresponds generally to otcpo 352 and 

If the data io valid at that time — (otcp 559) , — the taok 

can take itoelf off the liot — (otcp 561) . Alternatively, 

the taok may read the data and continue ito other oyotcm 

activities . Thio mcano that the taok may assume that the 

data wao initially found in the mailbox — (otcpo 563 and 

553 ) . A number of embodiments of the prcocnt invention 

have been deocribed. — Ncvcrthclooo, — it will bo undcrotood 
that variouo modif icationo may bo made, without departing 
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from the spirit and scope of the invention. For example, 

the number of lists may be increased to accommodate 

additional tasks . Accordingly, — it ia to be understood that 

the invention io not to be limited by the specific 
illustrated embodiments, but only by the scope of the 
appended claims. 

Method For Synchronisation of Multiple Asynchronous Threads 

Without Spin Locks, 
Busy Waits or Polling 

Current technology does not possess the ability to 
synchronize multiple asynchronous threads without employing 

busy waits, — or polling. This causes a waste of processor 

resources and limits the scalability of multi processors, 
because the likelihood of busy waits and the time consuming 

polling increases with the number of active threads. Eft 

addition, — it is inefficient with current technology to 
multi thread programs in which a largo number of elements 
effect the state and a largo number of elements take the 
state as input — (such as simulations) . 

An unlimited number of threads may interact without 

over busy waiting or polling in an embodiment. It is 

possible to write programs which can execute efficiently on 
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uni processors and arbitrarily largo multi processors 
without modification. 

A thread of execution may bo defined as a sequence of 
instructions which arc parsed out of memory and executed by 
the processing hardware and whose otatc is maintained on a 

single stack. A mailbox may be defined as an area of 

memory which contains at least two states — (usually called 

the valid state and the invalid state) . A multilist may be 

defined as a structure composed of two or more lists which 
logically act ao one list. 

Associated with this mailbox is at least one structure 
which can contain references to threads of execution which 
have been suspended ponding on of the permitted states of 
the mailbox. . One implementation of this structure is a 

linked list. Threads will contain instructions which 

reference this mailbox. One implementation of these 

instructions is as methods of a mailbox object. This 

instruction, — when executed, — tests the state of the mailbox, 
and if the state is one which permits the completion of the 
instruction — (called the valid otatc) , — completes the 

instruction . If the otatc of the mailbox is invalid, — fehe 

thread is placed on a list associated with the invalid 
state and the thread is suspended — (this method is 
appropriate for both user level control and system level 
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control . In this example only uoor level control will bo 

explained. In uoor level implementations, — the suspension 

io at user level and doco not involve a oyotcm call) . 
There is another kind of instruction which changes the 
state of the mailbox (Instructions may both wait on a state 

and change the state.) — from invalid to valid. When this 

inatruction io executed by any thread, — all threads on the 
newly valid wait list cease to be suspended and arc made 

runnable . The preferred methods may include many 

implementations of system level synchronisation and event 
mechanisms , 

A difficulty with any mechanism which suspends and 
resumes threads of execution is that a list must exist 
somewhere of the threads to be resumed and that more than 
one thread cannot be altering the list at any one time. 
This moans that the list must be locked when it order is 

being altered. If another thread requires access to the 

list, — it must wait its turn — (busy wait) . It docs not help 

to suspend the thread because that just requires another 

identical "wait list". It also does not help to pass the 

problem to a single thread because that also creates an 
identical list for the attention of the single thread (It 
also limits scalability by creating a limit on the number 
of processors which can perform a particular function) . 
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One embodiment included several parto and solves the 

general case of access contention. Applications include 

not only (synchronization, but aloo the general eaoc of 
concurrent programming as exemplified by simulations, — aftd 
by the non blocking acccoo to databases by multiple read 
and write operations. 

By using multiple lists (or queues etc.) — to record the 
waiting thrcado and allowing any thread which finds its 
first choice of lioto locked to uoc another one — (and 
another if that one io locked) , — the chancco of buoy waiting 
can be made arbitrarily small for any thread trying to got 

itself on the list. The chance of busy waiting can even 

fall to zero if the number of lists is equal to the number 

of threads needing access. This may not bo necessary 

because the probability of buoy waiting declines faster 
than exponentially and approaches zero — (becomes an 
insignificant barrier to scalability) — for very small 
numbers of lists. 

Accordingly, — a solution to the input problem may be to 
use multiple lists. 

If thread one findo the mailbox data invalid, — and goes 
to put itself on a list, but thread two, — after thread one 
has checked the data, makes the data valid and resumes all 
the threads on the list before thread one io even on the 
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wait list, — thread one will wait forever. This is a 

synchronization failure . The solution to thia 

synchronization problem io that thread one muat check back 
("one last look") — on the mailbox data after it has placed 

itself on the list and rclcaoed the liot. If it finds that 

the data is valid, — it must remove itself from the list and 

continue . Now it io impossible for the synchronization to 

fail. 

To reduce or eliminate the chance that a busy wait 
will occur because the reader and writer of synchronizing 
data contend for the same list, — since they must share 
access for the synchronization to have meaning, — access 

contention may occur. The solution to this access 

contention is as follows : 

A : A thread which is looking for its valid state, 

checks the mailbox data and if it is valid, — returns 
that data and continues . 

B ; If that thread finds the data invalid, — it finds an 
unlocked liot — (as above in part one) — and looks it. 
It then places itself on the list, — unlocks the list, 

and takes one last look at the mailbox data. If the 

data is still invalid the thread suspends itself. 
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C : If the data hao become valid, — the thread tries to 

lock the list on which it has placed itself. If the 

attempted lock fails, — the thread suspends itself, — i-fe 
will bo reawakened by whomever hao the liot locked. 

D ; If the lock succeeds, — the thread removes itoelf from 
the liot and causes all other members of the liot to 
resume . The thread then continues. 

I s A thread which is creating a valid state for the 
mailbox, — writes data indicating that state to the 
mailbox data area and then attempts to lock the 

first liot of the multilist. If the lock succeeds , 

the threads waiting on the liot arc caused to 

resume . The thread which wrote the valid data then 

repeats — (1 or 2) — the procedure on the next list of 
the multilist. 

2: If the lock attempt fails, — the list is skipped, — eta& 
the one locking the list will cause all of the 

threads on the liot to resume — (see D) . The thread 

which wrote the valid data then repeats — (1 or 2) — fehe 
procedure on the next liot of the multilist. 
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3: When the last liat of the multilist io completed, 
the thread which wrote the data will continue. 

This mcchaniam may guarantee that the synchronization 
mechanism will always be successful and that it will never 

buoy wait . Thio introduces a fixed amount of overhead to 

the communication and coordination of threads which doco 
not increase with the size of the program or the number of 
processors . This generally defines scalability. 

It may be useful to permit synchronisation on any 

Boolean. A Boolean "not" — can be implemented by having a 

thread have as its valid state of a particular mailbox the 
complement of another thread's valid state — (or zero and not 

zero etc . ) . A Boolean "or" — can bo implemented by having 

two or more threads write valid data to the same mailbox. 
A Boolean "and" can be implemented by having a single 

thread read two or more mailboxes in succession. With 

'not" , — "and" and "or", — all Boolcans can be encoded. This 

provides for the very useful control structure, — "whenever 
(general Boolean condition) , — de — (statement) " without 
polling. 

One problem io making simulations and other general 
programs concurrent . A method, — analogous to the 
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synchronization mechanism, — makes writing parallclizablc 
simulation programs — (and other inherently concurrent 
programs ) — easier . In this method : 

A: The data is replaced by a list is associated with 
consecutive integers and which can be added to on 
one end only — (an ordered list) . 

B : Multiple wait lists, — ordered by the integer position 
being waited on, — replace the multilist. 

C: A request for data passes an integer and returns the 
data associated with that integer if the integer is 

lower than or equal to the end of the list. If it 

is higher than the number — (any compare operator 
which divides the list at a point will do) , — fefee 
thread is placed on a wait list and the mechanism 
described above is used to resume it, — except that 
the tost of validity is whether the integer last 
written is equal to greater than the number 
requested . 

Another problem making simulations and other general 
programs concurrent is that there is not always an obvious 
way to determine whether all segments of the program which 
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might influence the inputo to a particular segment have 

executed. A method, — analogous to the synchronization 

mechanism, — makes writing paralloligablc simulation programs 

(and other inherently concurrent programs) — easier. In this 

method: 

A ; A map is made of the program, which models a space, 

in which regions may be defined as exclusively permitting 
the interaction of components in a particular circumstance. 
For instance, — in a driving simulation, — automobiles would 
only effect one another if they wore in identical or 

adjacent regions of the street map. The objects which move 

in the model may be attached to an arbitrary number of 
regions, — called interaction regions, — by enrolling in lists 

such as described in continuation 2 . Each region is 

required to report the transfers of object to its neighbors 
(a neighbor is a region which may accept an object from the 

region to which it is a neighbor) . When the number of 

reports equals the number of regions for a given integer 
value, — that integer value is current — (able to execute 
knowing all inputo are present) . — A preferred 
implementation is to count with a fetch decrement 
instruction and pass objects from region to region by using 
a list mail box. 
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Lock Free Record Management 

There are two reasons for lock records. One is to 

keep it from being altered in inconsistent wayo and the 

other is to protect it in come way. The first reason can 

bo eliminated. Currently, — locking dominates the coot of 

computing. Existing technology can do nothing to reduce 

this cost. 

A mechanism for ordering operations to provide the 
same result as if there wore locks without the need to 

block processes or threads is described. If the 

concurrency is high enough to overcome the inherent latency 
of access, — a high percentage of optimal computing 

efficiency can be achieved. Accordingly, — the number of 

necessary locks can be reduced. 

A thread of execution may bo defined as a sequence of 
instructions which arc parsed out of memory and executed by 
the processing hardware and whoso states is maintained on a 

single stack. A mailbox may be defined as area of memory 

which contains at least two states — (usually called the 

valid state and the invalid state) . A multilist can bo 

defined as a structure composed of two or more lists which 

logically act as one list. Associated with this mailbox is 

at least one structure which can contain references to 
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thrcado of execution which have boon ouopended pending one 

of the permitted otatco of the mailbox. One implementation 

of thia otructurc io a linked liot. Thrcado may contain 

inotructiono which reference thio mailbox. 9f*e 

implementation of thcoc inotructiono io a mcthodo of a 

mailbox object. An inotruction, — when executed, — tcoto the 

state of the mailbox, — and if the otatc io one which pcrmito 
the completion of the inotruction — (called the valid otatc) , 

completes the inotruction. If the otatc pf the mailbox io 

invalid, — the thread io placed on a liot aooociatcd with the 
invalid otatc and the thread io ouopended (Thio method io 
appropriate for both uoer level control and system level 

control . In thio example only uoer level control will be 

explained. In uoer level implcmcntationo , — the ouopenoion 

io at uoer level and doco not involve a system call) . 
There io another kind of inotruction, which changco the 
otatc of the mailbox — (Inotructiono may both wait on a otatc 

and change the otatc.) — from invalid to valid. When thio 

inotruction io executed by any thread, — all thrcado on the 
newly valid wait liot ccaoc to be ouopended and arc made 

runnablo. Many implcmcntationo of oyotcm level 

oynchronization and event mechaniomo can be included. A 

difficulty with any mochaniom, which ouopendo and rcoumco 
thrcado of execution io that a liot muot cxiot oomowhorc of 
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the threads to be roaumod and that more than one thread 

cannot bo altering the list at any one time. Thio means 

that the list must be locked when ito order io being 

altered. If another thread rcquiroo access to the list, — tfe 

must wait ito turn — (buoy wait) . It dooo not help to 

suspend the thread bocauoc that juot rcquiroo another 

identical "wait list". It also docs not help to pass the 

problem to a single thread because that also creates an 
identical list for the attention of the single thread — 
also limits scalability by creating a limit on the number 
of processors which can perform a particular function) . 
Applications include not only synchronization, — but also the 
general case of concurrent programming as exemplified by 
simulations, — and by the non blocking access to databases by 

multiple read and write operations. Generally, — the general 

case of access contention can be solved. 

A road modify write operation that may be added (such 
as LOCK XADD on the Pentium) — and can bo used to distribute 

locally unique consecutive numbers. Operations that must 

bo performed in order are assigned numbers such that the 

operation that must be done first has a lowor number. Each 

operator that can access tho database can place commands in 

a list sorted by number. So long as each operation 

executes on individual records in tho correct order, — fefee 
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rcoult must bo the game . That thia muot be true is obvious 

from the fact that all locks do is guarantee some 
inotruotion will occur before oomo others. 

A necessary instruction may not be delivered to the 
operation until an operation that needed to occur after it 
had already boon executed in the above read modify write 
operation. A synchronising mechaniom ohould exist. 
Instead of locks, — a block delivery oyotom can be used. 
Instructions that muot be executed in order arc delivered 
in blocks. The synchronising mechaniom can be mailboxco. 

Method for Adding and Subtracting within Limits without 

Blocking 

Current technology suffers from the inability to add 
or subtract from a shared memory location without locking 
the location during the operation if it is necessary to 
keep the value within limits or maintain a valid 
transaction log. Using the uninterruptible operations 
common to most general purpose CPUs, it is possible to add 
or subtract without blocking, provided that there are no 
limits and a valid transaction log is not necessary. 

It has been found that an unlimited number of threads 
to add and subtract from a single shared memory location 
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without blocking, overflow, or underflow. Further, the 
transaction log can always be valid so that error recovery- 
is possible. 

A thread of execution may be defined as a sequence of 
instructions which are parsed out of memory and executed by 
the processing hardware and whose state is maintained on a 
single stack. A shared value can be characterized as an 
area of memory that is accessible from at least two threads 
of execution. An uninterruptible instruction may be an 
instruction that reads an area of memory and does not 
permit another thread of execution to read or write that 
same area of memory until the instruction has completed. A 
limit can be defined as a value that the contents of a 
memory location must not pass (such as zero for inventory 
items or the end of allocated memory space for a pointer) . 

A single memory location can be included that may be 
accessed only by an interruptible add or subtract operation 
such as LOCK XADD (exchange and add) on the Pentium or a 
nondestructive operation such as a read. Such a device may 
safely permit many threads to add or subtract, but it is 
impossible to determine whether incomplete transactions 
have occurred or to execute instructions, such as extended 
precision, that require synchronization. 
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One more memory location (for a total of two) may be 
added that can be accessed by uninterruptible instructions 
only, whatever limits exist (limits may exist in one 
direction only) and a transaction log. Now an addition or 
subtraction is accomplished by adding (a negative number 
for subtraction) to one of the locations (each thread must 
use the two locations in the same order), if the operation 
does not place the total on the wrong side of the limits, 
then the operation is recorded in the transaction log and 
then added to the second memory location. If the total 
violates the limit (is smaller than the lower limit or 
larger than the upper limit) the number is subtracted from 
the first number. The failure may be recorded in a 
transaction log. Generally, this is an implementation 
detail. This device can guarantee a correct result, and 
that the total includes only valid operations, but it 
leaves a significant chance that a valid transaction will 
not occur. 

A preferred embodiment of the invention is practiced 
in the context of a conventional personal computer such as 
an IBM compatible personal computer, an Apple Macintosh 
computer or a UNIX-based workstation. FIG. [25] 1 shows a 
representative hardware configuration of a computer 2500 
including a central processing unit (CPU) 2510, such as a 
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microprocessor, and a number of other units interconnected 
via a system bus 2520. The computer 2500 may also include 
Read Only Memory (ROM) 2 540, Random Access Memory (RAM) 
2550, Non-Volatile Memory 2560, input devices 2570 (such as 
a keyboard, mouse, microphone, and touch screen) and output 
devices 2580 (such as a display screen, printer, and 
speaker) coupled to the system bus 2520. A Network 
Connection 2590 may be provided for connecting computer 
2500 to a communication network (not shown) such as an 
intranet or the Internet. The coomputcr computer 2500 
typically operates under control of an operating system 
such as the Microsoft Windows NT or Windows /98 OS, IBM 
OS/2, MAC OS, or UNIX operating system. Those skilled in 
the art will appreciate that the disclosed system and 
method can also be implemented on platforms and operating 
systems other than those mentioned. 

With reference to FIG. 2-&, a system for adding within 
limits without blocking is shown generally designated 2-&00. 
The system includes an actual value register 2-&10, a 
subtraction reservation register 2-6-2 0, an addition 
reservation register 2-6-30, a lower limit register 2-6-40, and 
an upper limit register 2-&50. RAM 2550 may include the 
registers 2410, 2420, 2430, 2440, and 2450. 
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A thread of execution including an atomic addition or 
subtraction operation (subtraction as addition of a 
negative value of an addend) is operable to operate upon 
the value stored in actual value register 2410. By way of- 
example, actual value register 2410 is shown to have a 
value of 7 which may include the value of current 
inventory . 

Subtraction and addition reservation registers 2-620 
and 2430 store a reserved value including the value of the 
actual value register 2410 after the operation. Thus for 
addition, the value of addition reservation register 2430 
is the actual value increased by the value of the addend 
and for subtraction the value of subtraction reservation 
register 2420 is the value of the actual value decreased by 
the value of the addend. 

Limit registers 2440 and 2450 store the value of the 
limits within which the operation is constrained. In the 
exemplary case of inventory control, the lower limit 
register 2440 is shown to have a value of 3 and the upper 
limit register 2450 is shown to have a value of 10. 

With reference to FIG. 23- 3, the method of the 
invention generally designated 2700 comprises a step 2710 
in which the value of the addend, -3 in the exemplary case 
indicating a request of 3 items of inventory, is obtained. 
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If the operation is addition, the value of the addend is 
positive, otherwise it is negative. 

In a step 2720 a LOCK XADD operation is performed upon 
the value stored in an affected reservation register using 
the addend. If the operation is addition, the affected 
reservation register is the addition reservation register 
2-&30, otherwise it is the subtraction reservation register 
2-&20. Thus in the exemplary case, the addend -3 is added 
to the subtraction reservation register 2-&20, resulting in 
a value of 4 in the subtraction reservation register 2-&20. 

In a step 273 0, the value of the affected reservation 
register is compared to the value of the limit registers 
2540 and 2550. In a step 2740, it is determined if the 
operation can succeed within the limits. In the exemplary 
case, the value of the subtraction reservation register 
2-6-2 0 is 4, which is greater than or equal to the lower 
limit of 3 stored in lower limit register 2540 and less 
than or equal to the upper limit of 10 stored in the upper 
limit register 2-&50. Therefore the operation can succeed 
within the limits. 

If the operation cannot succeed, in a step 2750, the 
value of the affected reservation register is restored by 
performing a LOCK XADD using the negative of the value. 
Thus in the example, 3 is added back to the value of 4 
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stored in the subtraction reservation register 2-&20 to 
restore the initial value of 7 stored in the subtraction 
reservation register 2-620. Finally, a failure is reported 
in a step 2760 and the process ends. 

If the operation can succeed, in a LOCK XADD operation 
2770, the addend is added to the value stored in the actual 
value register 2-610 and written to the actual value 
register 2£10. In a step 2780, in a LOCK XADD operation, 
the addend is added to the reservation register unaffected 
by the first LOCK XADD operation of step 2720. In the 
exemplary case, the unaffected reservation register is the 
addition reservation register 2660 230 and thus -3 is added 
to 7 and loaded into the addition reservation register 
2-6-60. Finally, in a step 2790, a success is reported and 
the process ends. 

A wait list with an uninterruptible counter may bo 
added. Now, — a thread of execution checks that the valuo 
could be added to the second memory location within the 
limit, — pcrformo an uninterruptible add on the first 
location aa above, — and if it succeeds, — then it proceeds as 

doocribod above. If it fails the toot against the limit, 

the second value I chocked. If the operation would succeed 

on the second value — (the operation to toot the occond value 
cannot alter it) , — the thread calculatoo tho chances of 
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success of each member of the wait list, — in order, — ignoring 
all members marked ao Gauging overflow and marking all 

members that cause overflow. If the value of thG second 

memory location pluo tho mcmbcra of the liot make it 
impossible to add the current value in without overflow, 
the value is subtracted back out of the first memory 

location and an overflow failure is reported. If the value 

can be succeed, — the thread adds one to the counter and 
places itself in the location that the counter indicates 
(such as value times address length plus offset) — with space 

for a read modify write operation. The thread then 

suspends for a time long enough to allow tho last thread to 
successfully complete an operation to have a chance to mark 
the reserved location to indicate tfhat tho thread should 

continue . This time should bo short enough to be otherwise 

benign. When the thread is reactivated it marks tho space 

reserved for read modify write operation that it is done, 
if it has not been otherwise marked, — then it subtracts tho 

value it added from tho first memory location. Tho last 

thread then marks members of the list that best exhaust tho 
remaining space to the limit — (application depended) — a**d 

goes on. This device guarantees that an optimal result 

will bo achieved without significant overhead and without 
much blocking, — but it docs not guarantee a unique last 
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thread. It io poooiblo that two thrcado will try to finioh 

allocating the remaining value to the limit, — and it io 
possible that some thrcado waiting to be serviced will bo 
missed . 

"One laot look" and synchronization conf igurationo may 

aloo be added. For implementation, — two locationo arc added 

to hold semaphores . A ocmaphoro may be defined ao a memory 

location only written to by uninterruptible inotruotiono . 

One caoc may be considered. When a value greater than one 

io added to the first total and cauoco the limit to bo 
exceeded, — but the oecond total io or hao some room left 

before hitting the limit. There muot be a oomaphorc in a 

known otatc — ( say reset) . The thread that oct the firot 

value paot the limit changoo the ocmaphoro — (oay ooto it) . 
It then oubtracto ito value from the first memory location. 
If the result io within limits, — the thread then checko the 

counter . If the counter io aero, it rcocto the ocmaphoro. 

If the counter io non zero , — it addo the value of each 

thread on the liot to the oecond total. Becauoc the 

ocmaphoro blocko other writing done after the ocmaphoro, 
and the firot counter wao known to be in boundo after the 

oomaphorc wao act, — there can be no caoc of overflow. ££■ 

the firot counter io out of boundo, — valuco on the liot arc 
oubtractcd from the firot counter until the counter io in 
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boundo , — then proceed ao before. Throado arriving at the 

device chock the semaphore. If it io reset, — they proceed 

ao in part three. If it io act, — the value of the occond 

memory location is checked. If it dooo not allow the 

transaction, — a failure io returned. If the second memory 

location hao a value that allows the tranoaction to 
complete, — then the value io added to the first location and 
the value to be added io placed on the liot and the thread 

io pauocd. When it awakens, if it marked ao added, — it 

rcturno ouggodg. If it io marked failed, — it returns 

failure . If it io unmarked — (moaning that io mi go connected 

with the thread that act the semaphore) , — then it subtracts 
its value from the firot memory location and begino again. 
Becauoc contention occuro only when a large value cxcccdo 
the limit becauoo other values were procoooed between the 
check of the occond value and the addition to the first 
value and smaller values are waiting to bo proccoocd, 

contention almost never occuro. Locks arc otherwise 

unnecessary. An incorrect result may never occur. 
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Lock Free Lioto 



With current methods, — it is noccooary to look a list 

to add or doloto a member . It hao been found that elements 

can be placed and removed without locko . 

The lioto may have many of the uocful propcrtico of 

queues without loeko. These devieco may aloo replace 

linked lioto without locks. 

The device may include a memory location and a 

contiguouo block of memory. The memory location and the 

block arc initialized a known value — (like zero) . Af*y 

thread of execution that would add to the liot creatco an 
array in memory and then addo one to the memory location 
with an uninterruptible inotruction — (ouch ao XADD on the 

Pentium) . From the value returned by the uninterruptible 

inotruction, — an addrooo in the contiguouo block of memory 
io computed. — A pointer may be placed there pointing to tho 

array juot created. A thread can remove an element from 

the liot by reading down the, liot and exchanging tho firot 

nonzero element with scro. Thio will be a pointer to an 

element of the liot. If tho thread trying to remove an 

element rcado paot tho current write pointer, — the liot io 
empty. 
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The contiguous block of memory may be divided into 
multiple parts. — Each part may have a memory location for a 

down counter and for a write location pointer. Each also 

may have a lowest unread pointer. In the rare case that a 

thread is suspended after it has gotten a write location 
and before it has written, — locations after it on the list 

will be removed before it. The lowest unread pointer that 

allows the search to start as far down the list as possible 

without missing anything. When the down counter, — which is 

decremented on each removal, — is zero, — the list may bo 

reused. This permits the list to act like a queue, — btt-fe 

without the locking of the head and tail pointers. fit 

scales) . 

A possible sequence may be implemented. i Pfee 

initializing process sots all of the memory to some known 

set of values that cannot be valid data. The down counters 

arc sot to the number of elements in a list section. The 

memory locations arc set to the head of their respective 

sections of the list. All of the memory locations that 

point to the head of a contiguous portion of memory arc 

placed in a list. The top of the list is pointed to in a 

master location. 

The writing process increments the first section 
pointer by the block size. The XADD instruction returns 
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the old value of the pointer, which is the top of the list. 
If writes into this location the pointer that it wishes to 

place in the queue. The process continues until the 

pointer equals the endpoint of the section. — , Then the 
writing process findo the firot ejection that is empty 
(down counter equals zero) , — sets the down counter to the 
section length and places the address of the ocction 

pointer in the master pointer. The next writer uses the 

next block referred to by the counter. 

The removing process reads down the section from the 

top until it finds a non zero element. It exchanges that 

element with zero. If a non zero value is returned, — that 

clement is removed and the responsibility of the remover. 
Otherwise, — it continuco to scan down until it succeeds in 

getting by uninterruptible exchange a non zero value. The 

removing process then decrements the down counter 
associated with the section in question and if the down 
counter equals zero , — marks the section empty and available 
for re use . 

Several embodiments arc specifically illustrated 

and/or described heroin. However, — it will bo appreciated 

that modifications and variations arc covered by the above 
teachings and within the scope of the appended claims 
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without departing from the apirit and intended ocopo 
thereof . 



/ 
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